Abstrakte Pakete sichern Flexibiltät

Dadurch werden die Auswirkungen von Veränderungen minimiert, was zu höherer architektonischer Integrität führt. Wir werden ein paar heuristische Methoden untersuchen, die dabei helfen können, dass die Beziehungen in einem Paket flexibel sind. Darüber hinaus werden wir auch untersuchen, wie diese heuristischen Methoden die Erstellung von Softwarearchitekturen unterstützen, die sehr flexibel und einfach zu pflegen sind.

Pakete müssen veränderbar sein

Pakete, von denen man stark abhängig ist, kompromittieren die architektonische Integrität, weil jegliche Veränderungen des Inhalts andere Teile, die auf das gleiche Paket angewiesen sind, beeinflussen. Wenn man dagegen von einem Paket nicht so stark abhängt, dann sind die Auswirkungen von Veränderungen weniger drastisch.

Die meisten Internet-Anwendungen erfordern einen Logging-Mechanismus, der es der Anwendung erlaubt, bestimmte Fehlerbedingungen zurückzuverfolgen, oder der beim Debugging helfen kann. Der Logging-Mechanismus ist meistens eine vorgefertigte Komponente, wie z.B. Log4j von Apache oder die neuen Logging-Funktionen in Java 2 v.1.4. Gleich welcher Mechanismus verwendet wird, eine starke Abhängigkeit vom Logging-Paket in der gesamten Applikation vergrößert inhärente Gefahren, jedes Mal, wenn der Inhalt des Logging-Pakets geändert wird.

Weil so viele Pakete im System vom Logging-Paket abhängen, ist es wichtig, die Wahrscheinlichkeit von Veränderungen zu minimieren. Einerseits kann man das erreichen, indem man Veränderungen auf solche Veränderungen in der Implementierung beschränkt, die keine Client-Pakete beeinflussen. Da eine externe Logging-Funktion verwendet wird, die man nicht beeinflussen kann, braucht man einen Ansatz, der die Auswirkungen von Veränderungen auf die Logging-Funktion minimiert. Ein allgemein üblicher Ansatz, um die Applikation vor Veränderungen in der zugrunde liegenden Implementierung zu schützen, ist das Facade-Modell. Abbildung A illustriert eine LoggingFacade-Klasse, die separat in der logfacade verpackt ist.

Abbildung A: Die LoggingFacade-Klasse (Abbildung vergrößern)

Diese Facade hilft, die Applikation vor Veränderungen der Logging-Implementierung zu isolieren. Alle Abhängigkeiten der Applikation vom Logging müssen zwangsläufig die logfacade durchlaufen. Selbst wenn die Logging-Implementierung häufige Veränderungen oder Upgrades erfordert, sind diese Veränderungen doch gut isoliert, und keine anderen Komponenten der Applikation sind vom Logging-Paket in hohem Maße abhängig.

Wenn die LoggingFacade-Klasse separat in ihrem logfacade-Paket verpackt ist, unterstützt sie jede einzelne der folgenden heuristischen Methoden, aus der Perspektive der Logging-Implementierung:

• auf Pakete, die sich am wenigsten ändern, sollte man sich am meisten stützen.
• auf Pakete, die sich am meisten ändern, sollte man sich am wenigsten stützen.

Das logfacade-Paket jedoch ist immer noch gefährlich, dadurch, dass Veränderungen Auswirkungen auf Komponenten haben können, die das logfacade-Paket nutzen. Wenn die vorhandene Logging-Komponente ausgetauscht oder eine andere Logging-Komponente als Option angeboten wird, dann kann die Isolation, die durch logfacade geboten wird, kompromittiert werden. Sie muss verändert werden, um die neue Implementierung zu unterstützen. Weil das logfacade-Paket in der gesamten Anwendung genutzt wird, muss man sicherstellen, dass das Paket so flexibel wie möglich ist. Abstraktion ist die Antwort.